PHP Conference Japan 2021
PHPer が知るべき MySQL クエリチューニング https://speakerdeck.com/mamy1326/what-phpers-need-to-know-about-mysql-query-tuning?slide=18
環境：Amazon AuroraでのMySQL 5.7
あるある
本番環境だとレコード数が多くてスロークエリになる
対策
staging環境を作れ
SQL単体で計測しろ
本番環境で実行するとプロセスが残る場合がある
phpMyAdminはkillされない
ピーク時間帯にスロークエリになる
対策
EXPLAINで確認、実測負荷テスト
レコード数が徐々に増えて突然フルスキャンが発生
検索対象が増えてフルスキャンのほうが効率的とoptimizerが判定する
対策
絞り込み条件を追加しろ
Cadinalityの偏り https://speakerdeck.com/mamy1326/what-phpers-need-to-know-about-mysql-query-tuning?slide=70
n:nのテーブルへのクエリ
テーブルごとにレコード数が全然違ったりしてい一部が遅くなる
対策
影響範囲を絞るために別テーブルにする
ポリモーフィック関連テーブルはアンチパターン
スロークエリの可視化
フレームワークのsqllogをくたｃて1つづつ実測・EXPLAIN
Amazon Cloudwatchの結果をSlack通知
DataDogでコード特定
頻度の高い（効果的な）クエリから対応する
分析・改善手法
EXPLAIN
インデックスのつかわれ方を見る
足りているか
検索しきれているか
対象が多すぎないか
インデックスの管理
削除
本番で確認する
アクセス状況が違う
master/replicaの前代で確認する
replicaしかつかわれてない場合がある
SELECTはreplicaだけにしている可能性がある
スロークエリ予防
レビュー
SQLから要件まで
基本
正規化できないか
カラム追加ではなく役割が違うのでは
テーブル分割
ポリモーフィック関連テーブルのCadinality偏り
論理削除
status？別テーブル？
レコード増加傾向
RDBに必要？
ログ（分析向けDB）？履歴本当に使う？
古いレコードはアーカイブできない？
ペアプロ
一緒に探す
わからないことをごまかさない
CIで追加されたSQLクエリを自動で検知して、パフォーマンスの問題を未然に防ぐ | ten-snapon.com
根本解決
要件と実装の間
PjM, PdMへの相談
PjM 説明、要件、ユーザー価値、リソース不足の理由、リスケ可能化、機能の重要度
PdM 品質影響、要件と実装、価値確認、リソース認識合わせ、品質確保体制
MySQLとインデックスとPHPer
https://speakerdeck.com/yoku0825/mysqltoindetukusutophper